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Abstract. A three-tiered specification approach is developed to formally specify 
collections of collaborating objects, say micro-architectures, (i) The structural 
properties to be maintained in the collaboration are specified in the lowest tier, 
(ii) The behaviour of the object methods in the classes is specified in the mid- 
dle tier, (iii) The interaction of the objects in the micro-architecture is specified 
in the third tier. The specification approach is based on Larch and accompany- 
ing notations and tools. The approach enables the unambiguous and complete 
specification of reusable collections of collaborating objects. The layered, for- 
mal approach is compared to other approaches including the mainstream UML 
approach. 
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1 Introduction 

Class vs. micro-architecture vs. framework An object-oriented system is a collection 
of encapsulated objects that collaborate among themselves to achieve specified tasks. 
The benefits of systems designed using OO principles include the potential for reuse, 
incremental extension and local modification. According to [ [25| ] and others, one can 
distinguish several levels of reuse and adaptation. At the lowest level, one reuses or 
adapts methods or classes. This level is often inadequate for reuse, and it does not 
appropriately scope adaptation activities since methods and classes are not "islands". 
They cannot be reused and adapted independently. At the highest level, one operates on 
entire application/rameworfcs'. This form does not account for application development 
with reuse of building blocks, neither does it restrict the scope of an adaptation. In fact, 
our target is the intermediate level of micro-architectures, that is, collections of collab- 
orating objects. We contend that this is the appropriate level for reuse and adaptation 
in object-oriented design and programming (OOD & OOP). 
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A running example Let us sketch an example of a micro-architecture. Our running ex- 
ample is the WorldClock micro-architecture dealing with interacting MasterClock and 
ZonalClock objects as illustrated in Figure [ij The MasterClock object is responsible for 
maintaining the Greenwich Meridian Time, while the ZonalClock objects display the 
time in their respective zones. The MasterClock object can exist independently of the 
ZonalClock objects, but each ZonalClock object depends on the MasterClock object to 
maintain its zonal time. We thus have a one-to-many relationship between master and 
zonal clocks. All the objects together maintain an invariant that any zonal clock dis- 
playing the time in its zone is consistent with the master clock's time. The MasterClock 
object notifies its associated ZonalClock objects whenever its time is updated. When 
a ZonalClock object is requested to update its zonal time, it queries the MasterClock 
object for the current time. If the ZonalClock object observes a time change then it up- 
dates itself to make its state (i.e., the zonal time) consistent with the time maintained 
by the MasterClock object. Explicit polling by the dependent ZonalClock objects for 
new information is not intended. The identities and the number of ZonalClock objects 
are not known a priori. Each ZonalClock object attaches itself to a MasterClock object 
upon its creation. 

Micro-architectures vs. design patterns Let us clarify our use of the term "micro- 
architecture" with regard to the related term "design pattern" [SJ. Recall our defini- 
tion: micro-architectures correspond to collections of collaborating objects. In fact, we 
consider micro-architectures to be the building blocks of object-oriented applications, 
especially of frameworks for domain-specific application development. A framework 
or an application contains several micro-architectures. In the actual code that embod- 
ies a framework, a certain class might contribute to more than one micro-architecture. 
By contrast, design patterns represent abstract, that is, application-independent designs. 



Especially, the operational meaning of design patterns is deliberately vague. One might 
say that design patterns are the most abstract micro-architectures one can think of, and 
hence we might consider micro-architectures as concrete instances of design patterns 
within frameworks. The typical micro-architecture in a framework is more concrete 
than a design pattern because it will usually exhibit some domain-specific behaviour. 
To give an example, the WorldClock micro-architecture is a concrete instance of the 
Observer pattern [p(i|]. While the WorldClock micro-architecture deals with the notion 
of time based on corresponding operations, the more abstract Observer pattern only 
involves an abstract notion of state. 

In need for a specification approach An informal explanation like the one given for the 
running example above is certainly informative for a developer who wants to reuse or 
to adapt a micro-architecture. However, in order to adequately deal with the complex- 
ity of design, improve productivity, and maintain acceptable levels of software quality 
the developer should also be provided with an unambiguous description of software 
components. Informal descriptions by themselves are grossly insufficient to build fu- 
ture software architectures, such as those being planned in strategic applications. The 
mainstream approach to specify designs of such architectures is to use UML [[32]]. One 
uses class diagrams to model the static structure of entities in the design, and one de- 
scribes the collaborations using object collaboration diagrams. Specifications of object 
interfaces are given in pseudo-code. This approach does not provide a clear description 
of object dependencies and the inter-object behaviours that are maintained in the collab- 
oration. Finally note that an UML-based specification is typically not formal, although 
there is admittedly an ongoing effort to provide a formal interpretation of certain UML 
notations. 

Three-tiered specification of micro-architectures We contend that we need a complete 
and formal approach to the specification of collections of collaborating objects. We also 
want this approach to be simple and to allow for a seamless integration with UML visual 
modelling facilities. A corresponding specification approach is the prime contribution 
of the present paper. Different aspects of micro-architectures are covered in three tiers: 

(i) the structural properties to be maintained by the collaboration; 

(ii) the roles of the collaborating objects in a black-box fashion; 

(iii) the interactive behaviour in terms of the operation sequences and flow of control. 

In our specification approach, we use a designated notation for each tier. The fist two 
tiers are covered by the formal specification language Larch [^2j, namely Larch traits 
and the Larch/C++ notation. We chose Larch because Larch makes it possible to ex- 
press externally observable behaviour in an implementation independent fashion which 
is crucial for black-box reuse. Larch/C++ provides built-in syntactic and semantic sup- 
port for specifying C++ class interfaces. This allows us to link specification and pro- 
gramming. As for the third tier, we use a simple logic of actions in the style of Lamport's 
Temporal Logic of Actions [p6||. 

Structure of the paper The three tiers or our specification approach are presented in the 
three sections ||-[5] accordingly. We provide the specification of the WorldClock example 
throughout these sections while the mainstream UML approach is considered as well. 
In Section [|, we report on related work regarding the specification of design structures 
such as micro-architectures or design patterns. In Section H, we conclude the paper. 



2 Lowest tier: Structure 



The lowest of the three tiers specifies the structural aspects of the collaboration. Besides 
specifying the data models for the objects in the collaboration, it also specifies the states 
of interest of each object, and the cardinality constraints of the relationships among the 
collaborating objects. We use the Larch Shared Language LSL [ p2[ ] for the specifica- 
tion of this layer. The section is structured as follows. We first recall the diagrammatic 
approach of UML corresponding to this layer. Then, we provide a brief description of 
LSL. Finally, we give a formal specification of the structural aspects of the WorldClock 
micro-architecture using LSL. 



2.1 UML class diagrams 

In Fig. ||, we show a class diagram of the WorldClock micro-architecture as used for 
OOD based on UML. This design could be enhanced to include object references and 
pseudo-code. 
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Fig. 2. Participating classes in the WorldClock micro-architecture 



There exists a one-to-many relationship between MasterClock and ZonalClock ob- 
jects. This relationship is expressed by means of the aggregation arrow in Fig. ||. In 
fact, a ZonalClock object cannot exist independently, and must be attached to a Master- 
Clock, while the converse is not true. There is a structural aspect which is not expressed 
in the class diagram. We require an integrity constraint on the relationship between the 
MasterClock object and the ZonalClock objects, that is, the ZonalClock time must be 
consistent with the MasterClock time in its zone. This integrity constraint corresponds 
to a structural aspect because it characterises the states of interest of the participating 
objects in the collaboration. 



2.2 The Larch Shared Language 



In our layered specification approach, LSL serves for the specification of structural 
aspects. Let us briefly recall LSL [|2| as a specification language. The unit of specifica- 
tion in LSL is the trait. A trait contains a set of operator declarations (say, a signature), 
which follows the introduces keyword, and a set of equational axioms, which follows 
the asserts keyword. Left- and right-hand side of an equation are separated by "==". 
A signature consists of operators the domains and ranges of which are represented by 
sorts. An equational axiom specifies the constraints on the defined operators. 

The semantics of LSL traits is based on multi-sorted first-order logic with equality 
rather than on an initial, final or loose algebra semantics used by other specification 
languages |P, p4pl| , p3| ] . Each trait denotes a theory, i.e., a set of logic formulae without 
free variables, in multi-sorted first-order logic with equality. The theory contains each 
of the trait's equations, the conventional axioms of first-order logic with equality, ev- 
erything which follows from them and nothing else. This means that the formulae in the 
theory follow only from the presence of assertions in the trait — not from their absence. 

LSL also provides a way of putting traits together through an includes clause. A 
trait that includes another trait is textually expanded to contain all operator declarations 
and axioms of the included trait. Boolean operators (true, false, not, V, A, — and <-»■) 
as well as some overloaded operators such as if-then-else and "="[] are built into the 
language, that is, traits defining these operators are implicitly included in every trait. 

LSL traits can be augmented with checkable redundancies in order to verify whether 
intended consequences actually follow from the axioms of the trait. The checkable re- 
dundancies are specified in the form of assertions that are included in the implies clause 
of a trait and can be verified using Larch Prover [^2|]. The theory of a trait can also be 
strengthened by adding a generated by or a partitioned by clause. The generated by 
clause states the operator symbols that can generate all values of a sort. The partitioned 
by clause provides additional equivalences between terms. It states that two terms are 
equal if they cannot be distinguished by any of the functions listed in the clause. 

2.3 Abstract states in the WorldClock micro-architecture 

We specify the abstract states of MasterClock and ZonalClock objects using LSL traits. 
Since both a MasterClock and a ZonalClock maintain time, we first specify the Time 
sort. This is followed by a specification of the Zone sort which provides the data model 
for ZonalClock objects. Ultimately, we specify the objects in the WorldClock micro- 
architecture including the relationship between them. 

The Time sort The LSL specification is shown in Fig. ||. The Time trait includes the traits 
TotalOrder(Time) and Integer. This is shown in the includes clause. The TotalOrder 
trait specifies formally the total ordering of the abstract values of Time. The signature 
and meaning of the operator "+" comes from the Integer trait defined in the LSL trait 
library. Comparison of time data is defined in terms of comparison of integers (cf. "<"). 

1 To avoid confusion, note that "=" is the built-in "equality" operator whereas "==" is used 
as the connective in equations. By convention, t == true is written as t. Also note that "=" 
binds more tightly than "==". Otherwise, the two operators are semantically equivalent. 
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Fig. 3. LSL specification of Time trait 



The "tuple of declaration specifies 7zme data as a record structure. The signature of 
the Time trait introduces the following functions: 

- currentTime: Returns the current time. 

- toint: Converts the given time into an integer. 

- fromlnt: Converts the given integer to time. 

- succ: Given a time unit, returns the next time. 

- pred: Given a time unit, returns the previous time. 

- inc: Given a time t and an integer i, returns t incremented by i seconds. 

- dec: Given a time t and an integer i, returns t decremented by i seconds. 

- max: Given two values of time, returns the maximum of the two. 

- min: Given two values of time, returns the minimum of the two. 

- < : Given two values of time, tests if the first is not later than the second. 

- isValid: Given a value of time, returns true for a valid time and false otherwise. 

The Zone data model The LSL specification of the data model for ZonalClock objects is 
shown in Fig. Since a zonal clock should also maintain a time, the Zone trait includes 
the Time trait. Besides the zonal time, the it Zone sort includes the name and offset of 
a zonal clock. Hence, the structure of Zone is a tuple of three fields. Here is a brief 
explanation of the trait's signature: 



Zone : trait 

includes Integer, String, Time 

Zone tuple of 
zonalName : String, 
zonalOffset : Int, 
zonalTime : Time 

introduces 

update : Time, Zone — > Zone 
isUpToDate : Time, Zone — > Bool 

asserts 

V z : Zone, t : Time 

update(t, z). zonalName = z. zonalName 

updateit, z) .zonalOffset — z. zonalOffset 

updateit, z) .zonalTime = fromInt(toInt(t) + z. zonalOffset) 

is Up To D ate (t, z) == z. zonalTime = fromInt(toInt(t) +z. zonalOffset) 

implies 

V z : Zone, t : Time 
isUpToDateit, update{t, z)) 



Fig. 4. LSL specification of Zone trait 

- update: Given a Time and a Zone, returns a Zone whose the zonal-time value is 
equal to the given Time incremented by the offset of the given Zone. 

- isUpToDate: Given a Time and a Zone, returns true if the zonal time is up-to-date 
with respect to the given master time, and false otherwise. 

The WorldClock trait The LSL specification of the objects in the WorldClock micro- 
architecture, and the invariant properties of the relationship between them is shown in 
Fig. |5| Note that this is the only trait which deals with (mutable) objects. Both Zonal- 
Clock and MasterClock objects are defined here. The other traits Time and Zone solely 
define the data models. Here is a brief description of the operators declared in the World- 
Clock trait: 

- masterOf: Given a ZonalClock object, returns the MasterClock object to which it is 
attached. The ZonalClock object depends on the MasterClock object for its current 
zonalTime. The totality of this function specifies the constraint that a ZonalClock 
object cannot exist independently of the MasterClock. 

- zonalClocksOf: Given a MasterClock object, returns the possibly empty set of at- 
tached ZonalClock objects that depend on the MasterClock. 

- isConsistent: Given a MasterClock, a ZonalClock, and a State, returns true if the 
two clocks are consistently related to each other in the state, and false otherwise. 

The specification of the trait relies on the MutableObj library trait that specifies the 
sort of mutable objects according to the formal LSL model for objects J3(i| ] including a 
corresponding notion of State. In the axioms, we use the binary operator "!" to extract 



WorldClock : trait 
includes 

MutableObj (Time, MasterClock for Obj[Time]), 
MutableObj (Zone, ZonalClock for Obj[Zone])), 
Set(ZonalClock, Set[ZonalClock]) 

introduces 

masterOf : ZonalClock — > MasterClock 
zonalClocksOf : MasterClock — > Set[ZonalClock] 
isConsistent : MasterClock, ZonalClock, State —* Bool 

asserts 

V m : MasterClock, z : ZonalClock, st : State 
\zonalClocksOf(m)\ > 

masterOf (z) = m == z 6 zonalClocksOf (m) 

isConsistent(m, z, st) == (masterOf (z) = m) A isUpToDate(m\st, z\st) 



Fig. 5. LSL specification of WorldClock trait 

the value of an object from a state. The trait performs three includes. Firstly, we in- 
clude "MutableObjiTime, MasterClock for Obj\TimeJ)" to specify the sort of mutable 
MasterClock objects whose abstract values are specified by the Time sort. The form 
"MasterClock for Obj[Time]" performs a renaming so that we can use the name Mas- 
terClock for the sort of MasterClock objects instead of Obj[Time]. Secondly, we include 
"MutableObj(Zone, ZonalClock for Obj[Zone]y to specify the sort of mutable Zonal- 
Clock objects. Thirdly, we include " Set(ZonalClock , ...)" so that we can deal with sets 
of ZonalClock objects, namely the set of ZonalClock^ attached to a MasterClock. The 
referenced library traits MutableObj and Set can be found in [|30|], 

3 Middle tier: Roles 

The middle tier in our three-tiered specification approach uses the data model defined in 
the lowest tier, and identifies the services required to specify the roles of the collaborat- 
ing objects to specify their externally observable inter-object behaviour. The role speci- 
fication for an object includes those services in the interface of the object which take part 
and are pertinent to the collaboration between the object and its collaborators. All the 
operations of an object's role are specified using a behavioural interface specification 
language (BISL). In the present paper, we have opted for Larch/C++ [f30||. While this 
concrete BISL interacts with C++, BISLs are also available for other programming lan- 
guages, e.g., for Java ^9fa. Hence, conceptually, our approach is language-independent. 

3.1 Informal explanation of services 

Before we discuss the Larch/C++ formalism and we employ it for the specification of 
our running example, we explain the services provided by the MasterClock object and 
the ZonalClock objects in an informal manner. Besides the object which provides a ser- 
vice, we often also need to point out further involved objects. To give an example, the 



service that creates a ZonalClock object forms part of role specification of the Zonal- 
Clock object, and the service involves the MasterClock object to attach the ZonalClock 
object to the MasterClock object. There are the following services: 

- MasterClock: This object provides an interface for attaching and detaching Zon- 
alClock objects. The services include the SetSecond method to update itself every 
second, the SetZonalClocks method to send notification to the ZonalClock^ when 
the MasterClock' 's time changes, the SetChange method to update its time and no- 
tify its ZonalClock^ of time change, and the GetTime method to query the current 
time corresponding to the Greenwich Meridian Time. 

- ZonalClock: This object provides an interface for creation so that a new instance 
is attached to a MasterClock object, and it also provides an updating interface to 
keep its state, namely its zonal time, consistent with the MasterClock'^ state via the 
methods UpdateZonalClock and SetZonalTime. 

Pseudo-code as used in UML would come close to such an informal definition. 
In addition, certain UML diagram forms could be used, e.g., collaboration diagrams 
or sequence diagrams. In our three-tiered specification approach, we want to provide 
behavioural specifications of the services. 

3.2 Behavioural interface specification in Larch/C++ 

An object's role specification defines a number of roles (say, interface functions, or 
methods for short). To this end, we have to indicate which trait it uses. This trait pro- 
vides the names and meanings of the operators referred to in the definition of the in- 
terface functions. Each such definition consists of a header and a body. The header 
specifies the name of the interface function, the names and types of parameters, as 
well as the return type (if any). We use the same notation as in Larch/C++ ftjdj. The 
body consists of an ensures clause as well as optional requires and modifies clauses. 
The requires and ensures clauses specify the pre- and post-condition respectively. The 
identifier self in the those assertions denotes the object that receives the corresponding 
message. The modifies clause lists those objects whose value may change as a result 
of executing the method. An omitted modifies clause is interpreted to mean that no ob- 
ject is modified — neither self nor any parameter objects. Finally notice the following 
conventions for referring to values and states in role specifications: 

- A distinction is made between an object and its value by using an unannotated 
identifier (for example, s) to denote an object, and a superscripted object identifier 
(for example, s" or s') to denote its value in a state. 

- The postfix operators " * " and " ' " for superscripting are used to extract values from 
objects. An object identifier superscripted by """ denotes an object's initial value 
and an object superscripted by " ' " denotes its final value. 

- The terms pre and post refers to the state just before or after the invocation of the 
specified method, respectively. The term any can be used when either of these will 
do. Each of these has the sort State which is the sort of the formal model of states 
in Larch/C++. If we want to access the value of an object o in a state st, then we 
use the notation o\st, e.g., self\any. 



MasterClock : role specification 

uses WorldClock 

Attach(z. ZonalClock) { 

modifies zonalClocksOf (self ); 
ensures z 6 zonalClocksOf(self); 

} 

Detach(z: ZonalClock) { 

requires z £ zonalClocksOf(self); 
modifies zonalClocksOf (self); 
ensures 2 ^ zonalClocksOf (self ); 

} 

Int GetTimeQ { 

ensures result — toInt(currentTime(self\any)); 

} 

SetSecondQ { 

modifies self; 

ensures self 1 — succ(self'); 

} 

SetZonalClocksQ { 

modifies containedObjects (zonalClocksOf (self ), pre); 
ensures Vz : ZonalClock (z S zonalClocksOf (self) => 
is Consistent (self , z, post)); 

} 

SetChangei) { 

modifies self A containedObjects (zonalClocksOf (self ), pre); 
ensures self' — succ(self) A Vz : ZonalClock 
(z 6 zonalClocksOf (self ) =>• is Consistent (self , z, post)); 

} 



Fig. 6. Role specification of MasterClock objects using the WorldClock trait 

3.3 Roles of the clock objects in the WorldClock micro-architecture 

In Fig. H and Fig. ^, the role specifications of MasterClock and ZonalClock objects are 
specified. The formal specifications directly implement our earlier informal explana- 
tions. Note how the operations from the lowest tier are employed. 

4 Highest tier: Interaction 

The highest tier employs the lower tiers to provide a specification of the interaction 
among the collaborating objects. The interaction between services provided in their 
roles must be specified in terms of operation sequences, and flow of control. These 
specify the state transformations of the object collaboration. In our formal specification 
approach, we use a simple designated action calculus for the interaction layer. 



ZonalClock : role specification 

uses WorldClock 

ZonalClock(m: MasterClock) { 
contructs self; 

ensures masterOf(self) — m; 

} 

UpdateZonalClockQ { 
modifies self; 

ensures isConsistent(masterOf(self), self , post); 

} 

SetZonalTime(i:Int) { 
modifies self; 

ensures self' — update(fromInt(i) , self); 

} 



Fig. 7. Role specification of ZonalClock objects using the WorldClock traits 

4.1 Sequence diagrams 

Before we discuss the formal specification of interaction, we recall the diagrammatic 
UML approach used in OOD. In Fig. ||, we illustrate a collaboration scenario for the 
WorldClock micro-architecture using a sequence diagram. We illustrate how aMaster- 
Clock interacts with aZonalClock and anotherZonalClock. It is not possible to capture 
that there could be arbitrarily many ZonalClock objects, and that the updates for all Zon- 
alClock objects could be done independent of each other, in parallel. We do not claim 
that such a diagrammatic is inherently informal. In fact, there are efforts to assign a 
formal and useful semantics to sequence diagrams and other UML notations. However, 
an inherent problem with formalising, using, and supporting UML is its complexity. 
We also refer to [[34J for a critical review of UML's suitability for the specification of 
design structures such as design patterns. We contend that our simple formal approach 
is complementary to UML. 

4.2 Classification of actions 

The interaction of collaborating objects will be specified using a logic of actions like 
Lamport's Temporal Logic of Actions po|. Before we deal with the actual forms of 
actions, we want to classify actions to gain a better understanding of interaction, and of 
the process in which smaller behaviours contribute to interactive behaviour. A simple 
action is in our case an invocation of a role of an object. Then, a compound action 
is composed from simpler actions by sequential composition and other means. Let us 
categorise actions regarding their possible effects. We first focus on categories of simple 
actions, that is, method invocations, or methods for short. The following categories 
capture whether a method affects the state of the associated object, or the objects in the 
environment, and whether the execution of the method returns a value: 
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Fig. 8. Sequence diagram for the WorldClock example 



- A V-method returns a value. 

- An O-method changes the abstract state of the object itself. 

- An £-method changes the abstract state of the object's environment. 

The categories V and O were inspired by a related categorisation in [Q]. By an object's 
environment, we shall mean any object other than the given object which is related in 
some way to the given object. The differentiated categories O and £ provide a more 
precise characterisation of the role behaviour. We assume that a method which belongs 
to the ^-category must always also belong to the 0-category, so that any change in 
the environmental state of an object is reflected by a change in the abstract state of the 
object itself. Further, we assume that methods which both perform state change and 
return a value can be reduced to methods which separate these concerns. Consequently, 
we assert that the role specifications from the middle tier are defined only with actions of 
the canonical combinations O, OS, and V. To give an example, one can easily observe 
the following categories for the role specification of MasterClock objects in Fig. |[ 

- O: Attach, Detach, SetSecond 

- OS: SetZonalClocks, SetChange 

- V: GetTime 

Slightly different kinds of categories had to be considered for compound actions be- 
cause they are typically concerned with several objects at a time. However, one could 
still define the environment of a given set of objects, and one could also consider the 
state local to a set of objects. We should assume a notion of atomicity for compound 
actions, that is, the intermediate state changes which are caused by steps of execution 
are not observable, but only the final state. A value -returning compound action could 
also be characterised easily. 



4.3 Action combinators 



An interaction specification defines actions on certain collaborating objects in terms of 
action combinators like independent or sequential collaboration. We group such defi- 
nitions per class. A single definition of an interaction is given as a method definition. 
The object the method of which is invoked and the objects occurring as method argu- 
ments are said to participate in an interaction. There is the following (abstract) syntax 
for interaction specifications: 



(Class names) 
(Method names) 
(Instance variables) 
(Types) 
(Guards) 
(Yielder) 



s ::= class c { i* } (Interaction specifications) c 

i ::= method m (v* ) { a} (Method definitions) m 

p ::= v : t (Parameters) v 

a ::= (Actions) t 

e.m ( e* ) (Method invocation) g 

a A a (Independent composition) y 

a; a (Sequential composition) 

a 1 1 a (Composition by choice) 

let v = a in a (Substitution) 
if g then a (Guarded action) 

while g do a (Iterated action) 

e ::= (Expressions) 
v (Instance variable) 

y (Yielder) 
This notation immediately suggests that interaction specifications can be simulated, 
say executed. A simple action is of the form "e.m(. . .)", and it denotes the object invo- 
cation restricted by pre- and post-condition of the role specification m for the object e 
given in the middle tier. An expression e is either an instance variable v, e.g., self, or a 
yielder, that is, the application of an operator from the lowest tier that yields an object 
(reference). We adopt the common convention to omit "self." in simple actions. 

There are three fundamental ways of binary action composition. Sequential compo- 
sition is used if the order of state changes matters, either because the actions operate 
on the same object (cf. category O), or they operate on an overlapping part of the en- 
vironment (cf. category £). By contrast, independent or parallel composition is used if 
the two actions do deliberately not interfere each other, that is, they operate on different 
"regions" of the state space. Finally, choice selects one out of two actions depending on 
which pre-condition evaluates to true. In the case that both pre-conditions evaluate to 
true, we deal with non-deterministic choice. The semantics of these forms of compound 
actions is defined as follows: 



Action ao 


Pre-/Postcondition 


ai A ai 


(pre(oo) => pne(oi) A pre(a,2)) A (post(ai) A post{a,2) =>■ post(ao)) 


a\\ a 2 


(pre(ao) => pre(oi)) A (post(ai) =>• pre(a2)) A (post(a,2) =>■ post(a a )) 


ai <J2 


((pre(ao) => pre(ai)) (post(ai) => post(ao))) 
V ((pre(ao) => pre(a,2)) => (post(a2) => post(ao))) 



We can generalise the two commutative, associative combinators for independent 
composition and choice to distributed versions accepting a set of actions as opposed 
to just two actions. The form "let v = a\ in a 2 " can be regarded as sequential 
composition with substitution: every occurrence of v in a 2 is substituted by a\, and 



class MasterClock { 

method SetZonalClocksQ { /\ zezona ici cksOf(self) z.UpdateZonalClock()} 
method SetChangeQ { SetSecondQ; SetZonalClocksQ } 

class ZonalClock { 
method ZonalClock(m : MasterClock) { m.Attach(self) } 
method UpdateZonalClockQ {if -i isConsistent(masterOf(self) , self , pre) 

then 

let i : Int = masterOf(self) .GetTimeQ 
in SetZonalTime(i) } 



Fig. 9. Interaction specification for WorldClock example 

then the action ci2 is performed. For simplicity, we might assume that ai is a simple, 
purely value-returning action (i.e., a V-method). 

There are two more combinators dealing with guarded and iterated actions. The 
action a\ in "if g then a\" is executed iff the guard g can be passed. As an aside, 
parallel collaboration can be used to define an "if g then . . . else . . ." if needed. The 
action "while g do ai" denotes a loop with pre-test. That is, the action ai is repeatedly 
performed as long as the guard g can be passed. Guards are applications of Boolean 
operators defined in the lowest tier. The semantics of if and while is the following: 



Action ao 


Pre-/Postcondition 


if g then ai 


((pre(ao) A G => pre(ai)) =>• (post(ai) =>• post(ao))) 




V (pre(ao) A -> G => post(ao)) 


while g do ai 


(pre(ao) A G => pre(ai)) 




A (post(ai) =>• pre(ao)) 




A (pre(ao) A -1 G =>■ post(ao)) 



This ends our exposition of action combinators for the specification of interactions 
between objects. Note how the tiers in our specification approach are layered. The low- 
est tier formalises Boolean operators needed for guards of conditionals and loops in 
the highest tier. The lowest tier also provides operators than can be applied to refer to 
objects in the interaction specification on the basis of the structural specification. Fur- 
thermore, the middle tier provides the roles invoked as the simple actions in the highest 
tier. Finally note that our set of action combinators for interaction does not include any 
form of assignment. State changes are solely encapsulated in the role specifications. 

4.4 Interaction specification for the WorldClock micro-architecture 

Our running example is completed in Fig. ^[ In this particular specification, for every 
name of an interaction, there happens to be an interface function of the same name in the 
role specifications. Consider, for example, the name SetChange. The role specification 
SetChange in the middle tier defines the behaviour in terms of pre- and postconditions 
whereas the method SetChange in the highest tier defines an interaction based on a 
sequence of two simpler method invocations. This is a checkable redundancy where the 
two specifications focus on different aspects of the object collaboration. In general, one 
might define compound actions which merely use services from the role specifications. 



Let us highlight some elements of the specification in order to illustrate the action 
calculus. In the specification of SetZonalClocks, the notation "A zezon aiciocksOf(seif) ■ ■ " i s 
used for distributed independent collaboration to point out that the UpdateZonalClock 
methods can proceed for all the relevant ZonalClocks independently of each other. In 
the specification of SetChange, sequential collaboration is used because it is essential 
that the MasterClock object invokes SetSecond and SetZonalClocks subsequently on 
itself. In the specification of the UpdateZonalClock, there is a guarded action. It models 
that the role "SetZonalTime(. . .)" only needs to be invoked if an update is due. The 
guard relies on the operator isConsistent from the lowest tier. Also, in order to retrieve 
the MasterClock object associated to self, we use the operator masterOf from the lowest 
tier. In this manner, we query a structural aspect of the WorldClock micro-architecture. 
The guarded action performs " SetZonalTime(i)" where i is substituted by the time 
that is obtained via an invocation of "masterOf (self). GetTimei)". 

5 Related work 

A good specification of the micro-architectures in a framework is indispensable to both 
the reuser of the framework and to the developer/maintainer of the framework. Yes, it 
is like saying that "every program must have a specification". If a reuser of the frame- 
work has to understand the framework, either the reuser could look at its underlying 
design patterns (which are very abstract), or (s)he could read the code to extract some 
behavioural insight (which is a waste of time). We contend that specifications of micro- 
architectures complement high-level designs such as UML diagrams, and that this mar- 
riage explains the behaviour of objects in the framework in an appropriate manner. Let 
us consider previous work on specification of object-oriented designs. 

In UML notation for class and sequence diagrams is enriched by certain pre- 
cise visual constraints which are useful for design-pattern descriptions. In order to spec- 
ify, for example, that a certain participating class can occur several times in an actual 
pattern instance, suitable Venn diagrams are used. This is an improvement over the style 
used in the GoF catalogue [ p0| ] where such constraints are treated in an informal man- 
ner, e.g., by giving an example with two sample classes. The enriched UML sequence 
diagrams covers in part the aspects captured in the middle and the highest tier in our 
approach. However, behavioural specifications are not an issue, neither does this UML 
approach adhere to a layered specification discipline. 

In [|27|], various design patterns are formally proved to be refinement transforma- 
tions in a semantical sense when compared to a more native/hard-wired encoding of the 
corresponding design pattern. To this end, an object calculus theory JT^ | is used as the 
semantical framework. This formal model does not aid the reusable behavioural spec- 
ification of micro-architectures, nor does it address the issue of object interaction. The 
work is geared towards a representation of design patterns in formal specifications for 
purposes of semantical reasoning. 

In [^4|, a logic on parse trees is used to specify and enforce constraints on a de- 
sign language. One can deal with architectural characteristics, or even with source code 
requirements in this manner. One possible application is to use the logic in order to 
enforce invariants of design-pattern instantiations. One can also use the mainstream 
language OCL to describe certain well-formedness constraints on an object-oriented 



design or a program. Such approaches emphasise structural or even syntactical invari- 
ants of micro-architectures, design patterns, or styles. Specification of behaviour and 
interaction is beyond the scope of these approaches. 

In [^TJ, design patterns are formally specified using the formal specification method 
DisCo for reactive systems. The formal basis of DisCo is Temporal Logic of Ac- 
tions [[26]]. In this setting, actions are understood as multi-object methods. These actions 
are atomic units of execution. An action consists of a list of participants and parame- 
ters, an enabling condition, and the definition of state changes caused by an execution of 
the action. An important contribution of this work is that it indicates how combination 
and instantiation of patterns in terms of their defining multi-object methods can be per- 
formed. The DisCo specifications roughly correspond to the interaction specifications 
in the highest tier. However, in our approach, it is essential that the interaction specifi- 
cations are defined on top of the other layers for structural and behavioural aspects of 
micro-architectures. 

In [p"3]l, a specification approach is described to capture design patterns and other 
building blocks. To this end, a declarative specification language LePUS corresponding 
to a subset of higher-order logic is employed. The prime idea is to define (say, constrain) 
object-oriented designs and their building blocks in terms of suitable sets of methods 
and classes, and relations on these. A non-trivial example is a so-called tribe which 
is a set of clans, that is, a set of methods which share a signature, in relation to a set 
of classes. Such a tribe is relevant in the specification of the Visitor pattern ftlOj. This 
approach addresses non-trivial structural properties but it is not suited to specify the 
behaviour of collections of objects, neither does it address object interaction. 

In [Q, object-oriented designs and design patterns are specified using RSL — the 
RAISE specification language [J35|]. This approach addresses weaknesses of informal 
and diagrammatic approaches in that it helps a designer to demonstrate conclusively 
that a particular problem matches a particular pattern, or that a proposed solution is 
consistent with a particular pattern. The proposed type of specification clearly captures 
more structural properties than a pure class diagram. The formal model also attempts 
to capture some behavioural characteristics such as the variables changed by a certain 
method invocation. Still the approach is rather syntactical in that it merely defines well- 
formedness relations on representations of object-oriented designs. Also, the approach 
neglects object interaction. 

In [S], a significant contribution to the problem of specifying micro-architectures 
is presented. The authors present a modelling construct called contracts for the specifi- 
cation of behavioural compositions. The paper illustrates that behavioural specifications 
are meaningful for refinement, conformance testing, and instantiation. The specification 
language is structured in the sense that different kinds of obligations or constraints are 
considered, namely typing, behavioural and contractual obligations. When compared to 
our specification language, contracts do not adhere to the multi-layered principle. Also, 
no formal syntax and semantics has been given for the specification language. This ham- 
pers tool support, and the verification of the correctness of programs that implement the 
micro-architectures. 

To summarise, previous approaches usually focus on only selected aspects of col- 
lections of collaborating objects while our approach identifies three different tiers to 



achieve full coverage. Most previous approaches involve informal ingredients. This is 
particularly true for the mainstream UML approach. By contrast, our simple formal 
approach is accessible for formal testing and verification. That is, Larch/C++ specifi- 
cations can be tested JTl|], and properties defined in terms of LSL traits can be veri- 
fied [^2|. Although our specifications are formal, they are immediately useful in the 
programming phase as supported by the Larch tool suite. Previous approaches usually 
emphasise the specification of design patterns. Note that behavioural specifications are 
not too much of an issue for design patterns. Even "behavioural" patterns [ p0| are rather 
"algorithm-free": their vague operational meaning is usually indicated via pseudo-code, 
and it can hardly be captured with specifications using pre- and postconditions or other- 
wise. By contrast, we focus on micro-architectures. These building blocks of domain- 
specific application frameworks usually exhibit some interesting behaviour subject to 
role specifications in our middle tier. 

6 Conclusion 

Three-tiered specification Our approach enables the reuser to understand the structural 
aspects (lowest tier), the behavioural aspects (middle tier) and the interactive aspects 
(highest tier) of collections of collaborating objects. The specification of behaviour in 
terms of roles depends on the specification of structural aspects. That is, the operators 
from the lowest tier are used in the pre- and postconditions in the middle tier. The 
specification of interaction between the collaborating objects in the highest tier invokes 
the roles of the objects specified in the middle tier, and operators from the lowest tier 
are used to query structural aspects. The three tiers achieve a separation of concerns. In 
each tier, a designated notation is favoured. Structural aspects are preferably specified in 
algebraic style as supported by LSL. Behavioural aspects are best described by contracts 
based on pre- and postconditions as supported by Larch/C++. Finally, the interaction 
of collaborating objects is best captured by an action calculus, say, a TLA-like logic. 
The approach adheres to a layered architecture principle. Lower tier specifications are 
imported into the next higher tier. Inclusion of a component from a higher tier to a 
component in a lower tier is not permitted, that is, there are no up-calls. This design 
permits improved reuse of components, and it allows changes to components in one 
layer without affecting the components in lower layers. In previous studies [|lj||,[3]], we 
have investigated the virtues of different variations on a three-tiered system architecture, 
and we have shown its expressiveness for the development of real-time reactive systems, 
E-Commerce systems, and evolving systems. For instance, the three tiers of a reactive 
system architecture respectively contain specifications of abstract data types, reactive 
classes, and system configurations. The contribution of the present paper is to capture 
our experience in a three-tiered specification approach. 

Evolving systems Let us indicate how our specification approach enables the evolution 
of a software system when requirements are revised or new ones need to be added. 
This will further clarify the usefulness of the specification approach in practice. System 
evolution is partitioned horizontally as well as vertically: evolution can happen in each 
tier, and propagation of change is across two successive tiers. To slightly generalise our 
WorldClock example from before, let us consider a system which involves publishers 
and subscribers instead of MasterClocks and ZonalClocks. This more abstract scenario 



corresponds to the Observer pattern [pOj] , also known as Publisher-Subscriber pattern. 
The pattern basically suggests that a publisher notifies any number of subscribers about 
changes to its state. Our layered specification approach offers the following advantages 
if a system involving publishers and subscribers evolves: 

- Traits can be refined for whatever reason of evolution in the first tier, and a refined 
trait may be included in a role specification to enrich the theory or strengthen data 
structuring. To give a simple example, if it is required for a publisher to maintain an 
ordered list of currently subscribed components, the Set trait can be refined to List 
in the first tier, and the List trait is then linked to the role specification. In general, 
changes which are local to the first tier, can be analysed prior to their propagation 
to the second tier. Refinement mappings for Larch traits are discussed in Jl2[], 

- An object can take both roles, that of a publisher as well as a subscriber, because in 
principle an object can subscribe to several publishers, and an object subscribing to 
a publisher may itself be a publisher for some other objects. If such a combination 
of responsibilities or services is required, then this is easy to achieve because role 
specifications in the second tier can be linked to several traits via the uses clause. 
Without layering, such requirements are difficult to model in a formal manner. 

- The publisher may decide which internal state changes it wants to share with its 
subscribers. It may also decide when and how to communicate such changes. These 
decisions are manifested in the role specification of the publisher. A revision of 
these decisions only requires local modifications in the middle tier. The interaction 
specification in the third tier will be "automatically" updated with the modified 
methods. In [Jl[], a theory is given for constructing composite classes and class re- 
finements. Evolution in the second tier would need to satisfy a similar theory. 

- Suppose the requirement of the publisher evolves such that the publisher is required 
to communicate state changes to its subscribers without the subscribers knowing 
the identity of the publisher. Then, we need to introduce a new role specification 
in the second tier, say Channel. In addition, the interaction components in the third 
tier have to be revised as follows: 

• the publisher interacts with the channel, and 

• the channel interacts with subscribers. 



Towards an integrated development method Each tier in our specification approach 
gives rise to an implementation layer. Also, the presented specification approach allows 
for a seamless integration of the three tiers with UML visual modelling facilities, au- 
tomated testing of Larch/C++ specifications [11], and verification of properties defined 
in terms of LSL traits [[Z2|]. The components in each layer can be individually analysed 
before before composition, adaptation, or reuse. It turns out that one important notion 
is missing in our layered approach to the specification of micro-architectures: we lack a 
sufficiently expressive and automated model for reuse of class structures. That is, to ac- 
tually deploy reusable micro-architectures or even design patterns in an actual applica- 
tion context, we need language constructs, tool support, and other means to adapt library 
structures, to replicate participants in a collaboration, to refine micro-architectures, and 
to compose behaviours of micro-architectures. In our ongoing research, we attempt to 
reuse ideas from programming support for design patterns J8| j],|]j^,[K)||l8|] and corre- 
sponding ideas for tool support for OOA/OOD/OOP [17,34 19 1. In particular, we plan 



to base the syntactical notion of reuse on superimposition of class structures as defined 
in our previous work [|lC 18 19[], This will eventually lead to a fully integrated software 
development method centered around the notion of micro-architectures. 
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